home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-07-25 | 51.2 KB | 1,403 lines |
-
-
-
-
-
-
- Network Working Group The North American Directory Forum
- Request for Comments: 1255 September 1991
- Obsoletes: RFC 1218
-
-
- A Naming Scheme for c=US
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
- Summary
-
- This RFC is a near-verbatim copy of a document, known as NADF-175,
- which has been produced by the North American Directory Forum (NADF).
- The NADF is a collection of organizations which offer, or plan to
- offer, public Directory services in North America, based on the CCITT
- X.500 Recommendations. As a part of its charter, the NADF must reach
- agreement as to how entries are named in the public portions of the
- North American Directory. NADF-175 represents the NADF's agreement
- in this area.
-
- Table of Contents
-
- 1 Introduction .......................................... 2
- 2 Approach .............................................. 2
- 2.1 Names and User-Friendliness ......................... 3
- 2.2 Choice of RDN Names ................................. 3
- 2.3 Outline of the Scheme ............................... 4
- 3 The Naming Process .................................... 4
- 3.1 Right-To-Use ........................................ 4
- 3.2 Registration ........................................ 6
- 3.3 Publication ......................................... 6
- 4 Structuring Objects ................................... 7
- 4.1 The National Level .................................. 7
- 4.2 The Regional Level .................................. 7
- 4.3 The Local Level ..................................... 9
- 4.4 ADDMD Operators ..................................... 10
- 4.5 Summary of Structuring Objects ...................... 11
- 5 Entity Objects ........................................ 12
- 5.1 Organizations ....................................... 12
- 5.1.1 Kinds of Organizations ............................ 12
- 5.1.2 Modeling Organizations ............................ 13
- 5.2 Persons ............................................. 14
- 6 Listing Entities ...................................... 15
- 6.1 Organizations ....................................... 15
-
-
-
- NADF [Page 1]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- 6.2 Persons ............................................. 16
- 7 Usage Examples ........................................ 17
- 7.1 Organizations with National-Standing ................ 17
- 7.2 Organizations with Regional-Standing ................ 18
- 7.3 Organizations with Local-Standing ................... 19
- 7.4 Organizations with Foreign-Standing ................. 20
- 7.5 Persons ............................................. 21
- 8 Bibliography .......................................... 22
- Appendix A: Revision History of this Scheme ............. 22
- Security Considerations ................................. 25
- Author's Address ........................................ 25
-
- A Naming Scheme for c=US
- The North American Directory Forum
- Supercedes: NADF-166, 143, 123, 103, 71
- July 12, 1991
-
- 1. Introduction
-
- Computer networks form the infrastructure between the users they
- interconnect, and networks are built on an underlying naming and
- numbering infrastructure, usually in the form of names and addresses.
- For example, some authority must exist to assign network addresses to
- ensure that numbering collisions do not occur. This is of paramount
- importance for an environment which consists of multiple service
- providers.
-
- 2. Approach
-
- It should be observed that there are several different naming
- universes that could be used in the Directory Information Tree (DIT).
- For example, geographical naming, community naming, political naming,
- organizational naming, and so on. The choice of naming universe
- largely determines the difficulty in mapping a user's query into a
- series of Directory operations to find useful information. Although
- it is possible to simultaneously support multiple naming universes
- with the DIT, this is likely to be unnatural. As such, this scheme
- focuses on a single naming universe.
-
- The naming universe in this scheme is based on civil authority. That
- is, it uses the existing civil naming infrastructure and suggests a
- (nearly) straight-forward mapping on the DIT. An important
- characteristic is that entries can be listed wherever searches for
- them are likely to occur. This implies that a single object may be
- listed as several separate entries.
-
-
-
-
-
-
- NADF [Page 2]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- 2.1. Names and User-Friendliness
-
- It must be emphasized that there are two distinct concepts which are
- often confused when discussing a naming scheme:
-
- (1) user-friendly naming:
- a property of a Directory which allows users to easily
- identity objects of interest; and,
-
-
- (2) Distinguished Name:
- the administratively assigned name for an entry in the
- OSI Directory.
-
- It must be emphasized that Distinguished Names are not necessarily
- user-friendly names, and further, that user-friendly naming in the
- Directory is a property of the Directory Service, not of
- Distinguished Names.
-
- 2.2. Choice of RDN Names
-
- The key aspect to appreciate for choice of RDNs is that they should
- provide a large name space to avoid collisions: the naming strategy
- must provide enough "real estate" to accommodate a large demand for
- Distinguished Names. This is the primary requirement for RDNs. A
- secondary requirement is that RDNs should be meaningful (friendly to
- people) and should not impede searching.
-
- However, it is important to understand that this second requirement
- can be achieved by using additional (non- distinguished) attribute
- values. For example, if the RDN of an entry is
-
- organizationName is Performance Systems International
-
- then it is perfectly acceptable (and indeed desirable) to have other
- values for the "organizationName" attribute, e.g.,
-
- organizationName is PSI
-
- The use of these abbreviated names greatly aids searching whilst
- avoiding unnecessary Distinguished Name conflicts.
-
- In order to appreciate the naming scheme which follows, it is
- important to understand that wherever possible it leverages existing
- naming infrastructure. That is, it relies heavily on non-OSI naming
- authorities which already exist. Note that inasmuch as it relies on
- existing naming authorities, there is little chance that any "final"
- national decision could obsolete this scheme. (Any naming scheme may
-
-
-
- NADF [Page 3]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- be subject to the jurisdiction of certain national agencies. For
- example, the US State Department is concerned with any impact on US
- telecommunications treaty obligations.) To do so would require a
- national decision that disregards existing national and regional
- infrastructure, and establishes some entirely new and different
- national naming infrastructure.
-
- 2.3. Outline of the Scheme
-
- The naming scheme is divided into four parts:
-
- (1) a discussion of the right-to-use, registration, and
- publication concepts;
-
- (2) a discussion of objects with national, regional, local,
- and foreign standing;
-
- (3) a discussion of objects which may be listed at
- national, regional, and local levels; and,
-
- (4) a discussion of how RDNs are formed for listing entries
- at each different level.
-
- 3. The Naming Process
-
- There are three stages to the naming process.
-
- 3.1. Right-To-Use
-
- First, a naming authority must establish the right-to-use for any
- name to be used, within the jurisdiction of the given naming
- authority. Names that are used in public are generally constrained
- by public laws. Names that are only used in private are a private
- matter. We are primarily concerned here with public names because
- these are the names that are most interesting to enter into public
- directories where we can search for them.
-
- There is a global governmental/civil/organizational infrastructure
- already in place to name and number things like people, cars, houses,
- buildings and streets; localities like populated places, cities,
- counties, states, and countries; organizations like businesses,
- schools, and governments; and other entities like computers,
- printers, ports, routers, processes, files, filesystems, networks,
- management domains, and so on. There are also naming (and numbering)
- authorities for various standards and for networks (e.g., ISO/IEC,
- CCITT, IANA) which depend on acceptance by their constituent
- communities for their authority.
-
-
-
-
- NADF [Page 4]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- This collective infrastructure is comprised of a very large number of
- authorities that we will call naming authorities. Naming authorities
- tend toward hierarchical organization. Parents have authority
- (granted by government) to choose the names of new-born children, the
- courts have authority to change a person's name, car makers have
- authority to name the models of cars they build (within the limits of
- trademarking law), and they are obligated to assign unique serial
- numbers to each car. Cities assign names to their streets and
- districts, states assign city, county, and township names, and so on.
- State governments also assign names to "registered" organizations
- that operate under state charters, which in turn name their own
- suborganizations. Cities and Counties license businesses to use
- their chosen (unambiguous) names "in association with" the city and
- county names. Companies name and number the computers and
- communications devices they make and sell. There are many many name
- spaces, some of which are subordinate to others, and some of which
- are independent.
-
- Public names must be "registered" in some "public record" to record
- the fact of the assignment of the right-to-use to specific "owners."
- In general, this is to prevent collisions of the right-to-use
- assignments in public shared name spaces. For example, unique names
- given to corporations are registered by the state of incorporation.
- A request to use a new name for any corporation must not conflict
- with the name of any other corporation registered in the same state.
- The same applies for businesses licensed within cities and counties.
-
- Establishment of the right-to-use for a name is not a Directory
- Service. The right-to-use for a name is always derived from some
- other (non-directory) source of authority because of the legal
- aspects of intellectual property rights which are entirely outside
- the scope of directory service specifications. People and
- organizations attach great value to the names they are allowed to
- associate with their lives and businesses, and intellectual property
- law protects their interests with respect to these values.
-
- This is not to say that directory service designers and providers
- have no interest in the processes and procedures for establishment of
- the right-to-use for the names that will be entered into any
- directory. Indeed, without a supply of rightfully-usable names,
- there cannot be any directory. But, given an adequate supply of
- registered names, the directory service is not otherwise concerned.
-
- We should note here that some naming authorities must deal with name
- spaces that are shared among large communities (such as computer
- networks) in which collisions will occur among applicants for desired
- name assignments, while other name spaces (such as for given names of
- children in a family) are not shared outside the family. Sharing is
-
-
-
- NADF [Page 5]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- always a problem, which has led to trademarking laws, business
- license laws, and so on. Naming within organizations should be
- easier, because it is "in the family," so to speak. Hierarchical
- naming schemes facilitate distribution of naming authority.
-
- 3.2. Registration
-
- Second, a name may be bound (as a value) to some object attribute.
-
- Given the right to use a name, a Naming Authority, such as a family
- which has an inherited surname and, more or less, has the right to
- use any names it pleases for its children's given names, must bind
- selected names to selected object attributes (e.g., firstname=Einar).
- Note that this same name might also be used as the first name or
- middle name of other children, as long as each sequence of given
- names of each family member is distinguished (i.e., none are
- duplicates) within the family. Wise families do not bind the same
- sequence of given names to more than one child. Some avoid any
- multiple use of a single name. Some use generational qualifiers to
- prevent parent-child conflicts.
-
- The Internet Domain Name System (DNS) names top level domains which
- are then free (within some technical limits) to chose and bind names
- to entries which are subordinate to a given named domain, and so
- forth down the DNS name tree. The ISO/CCITT naming system serves the
- same purposes in other separate name spaces.
-
- 3.3. Publication
-
- Third, after binding, a name must be advertised or published in some
- community if it is to be referenced by others. If it is not
- advertised or published, then no one can refer to it.
-
- This publication stage is what the Directory Service is all about.
- The Directory contains entries for "listed" names (or numbers) that
- are bound to the attributes of the entries in the directory DIT.
- Historically speaking, the directory business is a subclass of the
- publishing business, serving to dereference names into knowledge
- about what they stand for.
-
- It is important to keep in mind that a directory "listing entry" is
- not a "registration" unless a particular segment of the directory
- also just happens to be the authoritative master register of some
- naming authority. Registration and listing are very different
- service functions, though it is conceivable that they might be
- combined in a single DIT.
-
- For example, in the United States of America, each state name is
-
-
-
- NADF [Page 6]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- registered by the Congress by inclusion of the name in the
- legislation that "admits each State into the Union." Note however
- that the name is also then published in many places (such as on maps
- and in directories), while the master "register" is kept with the
- other original records of laws enacted by the Congress and signed by
- the President. Also, the name is then entered (listed) in many
- directories, in association with the name "The United States of
- America." And so on down the civil naming tree, with entities named
- in each state, etc. It is certainly not the case that the American
- National Standards Institute (ANSI) registers the names of the States
- in the United States of America! That right and duty is clearly
- reserved to the Government of the United States of America.
-
- On the other hand, in the Internet DNS, the act of inserting a given
- rightfully-usable name and address entry into a nameserver
- constitutes simultaneous registration and directory publication.
-
- 4. Structuring Objects
-
- The first step in providing a civil naming infrastructure is to model
- the geographical/governmental entities which provide a basis for the
- assignment of public names.
-
- 4.1. The National Level
-
- The nation is modeled with an object of class "country", subordinate
- to the root of the DIT, and has an RDN consisting of a single
- attribute value assertion:
-
- countryName= US
-
- The entry (minimally) contains these attributes:
-
- objectClass= country
- description= United States of America
-
- 4.2. The Regional Level
-
- Within the nation, there are regions. Each region corresponds to a
- state or state-equivalent as recognized by the US Congress. The list
- of these is maintained in US FIPS 5. A sample entry from this FIPS
- document looks like this:
-
-
-
-
-
-
-
-
-
- NADF [Page 7]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- +------------+---------+-------+
- | | State | State |
- | FIPS-5 | Numeric | Alpha |
- | Name | Code | Code |
- +------------+---------+-------+
- | | | |
- | California | 06 | CA |
- | | | |
- +------------+---------+-------+
-
- Each region is modeled with an object of class
- "usStateOrEquivalent", which is defined thusly:
-
- usStateOrEquivalent OBJECT-CLASS
- SUBCLASS OF locality, nadfObject
- MUST CONTAIN { localityName,
- fipsStateNumericCode,
- fipsStateAlphaCode,
- stateOrProvinceName }
-
-
-
- Each entry is subordinate to "c=US", and has an RDN consisting
- of a single attribute value assertion:
-
- stateOrProvinceName= <FIPS-5 name>
-
- e.g.,
-
- stateOrProvinceName= California
-
-
- Each entry (minimally) contains these attributes:
-
- objectClass= usStateOrEquivalent
- description= <official name of region>
- localityName= <FIPS-5 name>
- localityName= <FIPS-5 state alpha code>
- fipsStateAlphaCode= <FIPS-5 state alpha code>
- fipsStateNumericCode= <FIPS-5 state numeric code>
-
- e.g.,
-
- objectClass= usStateOrEquivalent
- description= State of California
- localityName= California
- localityName= CA
- fipsStateAlphaCode= CA
-
-
-
- NADF [Page 8]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- fipsStateNumericCode= 06
-
- 4.3. The Local Level
-
- Within each region, there are places. Each place corresponds to a
- county or county-equivalent as recognized by the regional government.
- The list of these is maintained in US FIPS 55 as a populated place
- with a five-digit numeric place code starting with "99." A sample
- entry from this FIPS document looks like this:
-
- +---------+---------+-------+-----+----------------------+-----+
- | State | Place | State | | | |
- | Numeric | Numeric | Alpha | | FIPS-55 | |
- | Code | Code | Code | | Name | |
- +---------+---------+-------+-----+----------------------+-----+
- | | | | | | |
- | 06 | 99085 | CA | ... | Santa Clara (County) | ... |
- | | | | | | |
- +---------+---------+-------+-----+----------------------+-----+
-
- (Any parenthetical text in the FIPS-55 name is considered a
- "remark" about the place.)
-
-
- Each county is modeled with an object of class
- "usCountyOrEquivalent", which is defined thusly:
-
- usPlace OBJECT-CLASS
- SUBCLASS OF locality, nadfObject
- MUST CONTAIN { localityName,
- fipsPlaceNumericCode }
-
- usCountyOrEquivalent OBJECT-CLASS
- SUBCLASS OF usPlace
- MUST CONTAIN { fipsCountyNumericCode }
-
- Each entry is subordinate to the entry naming the region which
- contains the county, and has an RDN consisting of a single
- attribute value assertion:
-
- localityName= <FIPS-55 name without remarks>
-
- e.g.,
-
- localityName= Santa Clara
-
-
- Each entry (minimally) contains these attributes:
-
-
-
- NADF [Page 9]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- objectClass= usCountyOrEquivalent
- fipsPlaceNumericCode= <FIPS-55 place numeric code>
- fipsCountyNumericCode= <last three digits of FIPS-55
- place code>
- stateOrProvinceName= <FIPS-55 state alpha code>
- stateOrProvinceName= <FIPS-5 corresponding name>
- description= <FIPS-55 name with remarks>
-
- e.g.,
-
- objectClass= usCountyOrEquivalent
- fipsPlaceNumericCode= 99085
- fipsCountyNumericCode= 085
- stateOrProvinceName= California
- stateOrProvinceName= CA
- description= County of Santa Clara
-
- In addition, for each populated place named within the county,
- a non-distinguished "localityName" attribute value may be
- present to aid searching, e.g.,
-
- localityName= Mountain View
- localityName= San Jose
-
- and so on.
-
- 4.4. ADDMD Operators
-
- Also within the nation, there are public Directory service providers.
- Each service-provider corresponds to an ADDMD operator as recognized
- by the NADF. Each ADDMD operator is modeled with an object of class
- "nadfADDMD", which is defined thusly:
-
- nadfADDMD OBJECT-CLASS
- SUBCLASS OF nadfObject
- MUST CONTAIN { addmdName }
- MAY CONTAIN { organizationName,
- organizationalAttributeSet }
-
- Each entry is subordinate to "c=US", and has an RDN consisting of a
- single attribute value assertion:
-
- addmdName= <NADF registered name>
-
- e.g.,
-
- addmdName= PSINet
-
-
-
-
- NADF [Page 10]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- Each entry (minimally) contains this attribute:
-
- objectClass= nadfADDMD
-
- The structure of the subtree below each "nadfADDMD" entry is a matter
- for that service-provider to establish. It must be emphasized that
- such entries are used to provide a "private" namespace for each
- service provider, as envisioned in NADF-128. This "nadfADDMD" entry
- is distinct from a service provider's "organization" entry which
- would be used to contain organizational information about the service
- provider.
-
- 4.5. Summary of Structuring Objects
-
- To summarize the naming architecture thus far:
-
- +---------------+-----+---------------------+-----+--------------------+
- | Level |Elem | objectClass |Supr | RDN |
- +---------------+-----+---------------------+-----+--------------------+
- | root | 0 | | | |
- +---------------+-----+---------------------+-----+--------------------+
- | international | 1 | country | 0 | countryName |
- +---------------+-----+---------------------+-----+--------------------+
- | national | 2 | usStateOrEquivalent | 1 | stateOrProvinceName|
- | | 3 | nadfADDMD | 1 | addmdName |
- +---------------+-----+---------------------+-----+--------------------+
- | regional | 4 | usCountyOrEquivalent| 2 | localityName |
- +---------------+-----+---------------------+-----+--------------------+
- | local | 5 | ... | 4 | ... |
- +---------------+-----+---------------------+-----+--------------------+
-
- Or, in pictorial form:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- NADF [Page 11]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- root
- /
- /
- /
- (----)
- (c=US)
- (----)
- / | \
- / | \
- /------------/ | \------\
- / | \
- for each state or (------) / \ (---------) for
- state-equivalent (st=...) / \ (addmd=...) each
- (------) / \ (---------) ADDMD
- / \ / \
- / \ /national \
- /------------/ \ / listings \
- / \ -------------
- / \
- (-----) for each /\
- (l=...) county or / \
- (-----) county-equivalent / \
- | / \
- | /regional\
- | / listings \
- | ------------
- / \
- / \
- / \
- / local \
- /listings \
- -----------
-
-
- 5. Entity Objects
-
- The next step in using the civil naming infrastructure is to model
- the entities which reside within the geographical/governmental
- structure.
-
- 5.1. Organizations
-
- Organizations exist at several levels.
-
- 5.1.1. Kinds of Organizations
-
- An organization is said to have national-standing if it is chartered
- (created and named) by the US Congress. An example of such an
-
-
-
- NADF [Page 12]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- organization might be a national laboratory. There is no other
- entity which is empowered by government to confer national-standing
- on organizations. However, ANSI maintains an alphanumeric nameform
- registration for organizations, and this will be used as the public
- directory service basis for conferring national-standing on private
- organizations.
-
- An organization is said to have regional-standing if it is chartered
- by the government of that region. An example of such an organization
- might be a public university. In addition, private organizations may
- achieve regional-standing by registering with the "Secretary of
- State" (or similar entity) within that region -- this is termed a
- "doing business as" (DBA) registration.
-
- NOTE:
-
- An organization may have a DBA registration in several states,
- even though it is incorporated in only one state. Where an
- organization registers itself is largely dependent on where it
- might choose to incorporate, and where it might choose to
- locate (and license) its business operations.
-
- For example, a large organization might have a DBA registration
- in most of the 50 states, and be incorporated in Delaware. For
- the purposes of this naming scheme, such an organization is
- said to have regional-standing in each state where it has a DBA
- registration. This DBA registration confers the sole right to
- use the DBA name in association with the named jurisdiction of
- the registration authority.
-
- An organization is said to have local-standing if it is chartered by
- a local government within that place. In addition, private
- organizations may achieve local-standing by registering with a
- "County Clerk" (or similar entity) within that place -- this is
- termed a "doing business as" (DBA) registration. Note that local-
- standing is somewhat ambiguous in that there may be multiple local
- governments contained within a county or county-equivalent.
- Depending on local government rules of incorporation and containment,
- registering with one entity may prevent others from registering that
- same name with other entities contained within that place. In order
- to avoid ambiguity, other distinguishing attributes, such as
- "streetAddress", may be needed to provide uniqueness.
-
- 5.1.2. Modeling Organizations
-
- In the DIT, an organization is modeled with an object of
- class "organization". In addition, some combination of the
- following auxiliary object classes might also be used:
-
-
-
- NADF [Page 13]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- (1) if an organization has national-standing derived from
- ANSI registration, then this is modeled by including in
- the entry an object class attribute value of
- "ansiOrgObject", which is defined thusly:
-
- ansiOrgObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN { ansiOrgNumericCode }
-
-
- (2) if an organization has national-standing (either in the
- US or some other nation), then it may be necessary to
- identify the country which corresponds to the registry
- which names the organization. This is modeled by
- including in the entry an object class attribute value
- of "nationalObject", which is defined thusly:
-
- nationalObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN { countryName }
-
-
- (3) if an organization has local-standing, then it may be
- necessary to identify the place in US FIPS 55 which
- corresponds to the registry which names the
- organization. This is modeled by including in the
- entry an object class attribute value of
- "fips55Object", which is defined thusly:
-
- fips55Object OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN { fipsPlaceNumericCode }
- MAY CONTAIN { stateOrProvinceName }
-
- 5.2. Persons
-
- There are two kinds of entries for a person: organizational person
- and residential person.
-
- Definitions for an organizational person are a local matter to be
- decided by each organization. It is suggested that an organizational
- person be modeled with an object of class "organizationalPerson".
-
- Outside of organizations, persons exist only in a residential context.
- As such they always have local standing. For a given person, it
- should always be possible to identify the place in US FIPS 55 which
- corresponds to the "smallest" populated place where any person
- resides, and then use the code associated with that place to aid in
-
-
-
- NADF [Page 14]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- distinguishing the person. A residential person is modeled with an
- object of class "residentialPerson". In addition, since it may be
- necessary to identify the place in US FIPS 55 which corresponds
- to where the person resides, an object class attribute value
- of "fips55Object" may be present in entries corresponding to
- residential persons.
-
- 6. Listing Entities
-
- The final step is to define how entities are listed within the
- context of the civil naming infrastructure. Note than an entity may
- have several listings (DNs) in different parts of the Directory.
-
- 6.1. Organizations
-
- The RDN used when listing an organization depends on both the
- standing of the organization, and where the listing is to be placed:
-
- +----------------------------------------+
- +-------------------| Listing (RDN) under |
- | Entity | c=US | c=US, st=X | c=US, st=X, l=Y |
- +-------------------+---------+------------+-----------------+
- | national-standing | o | o, c=US | o, c=US |
- +-------------------+---------+------------+-----------------+
- | regional-standing | o, st=X | o | o |
- +-------------------+---------+------------+-----------------+
- | .. (other region) | | o, st=Z | o, st=Z |
- +-------------------+---------+------------+-----------------+
- | local-standing | o, st=X | o, fips55 | o, fips55 |
- | | fips55 | | |
- +-------------------+---------+------------+-----------------+
- | .. (other region) | | o, st=Z | o, st=Z, fips55 |
- | | | fips55 | |
- +-------------------+---------+------------+-----------------+
- | foreign-standing | o, ... | o, ..., c | o, ..., c |
- | | c | | |
- +-------------------+---------+------------+-----------------+
-
- This scheme makes no requirements on the DIT structure within
- an organization. However, the following naming architecture
- is suggested:
-
-
-
-
-
-
-
-
-
-
- NADF [Page 15]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- +----------------+-----+----------------------+----------+-------------+
- | Level |Elem | objectClass | Super | RDN |
- +----------------+-----+----------------------+----------+-------------+
- | listing | 11 | organization | 1,2,4 | |
- +----------------+-----+----------------------+----------+-------------+
- | organizational | 12 | organizationalUnit | 11,12,13 | orgUnitName |
- | | 13 | locality | 11,12,13 | localityName|
- | | 14 | organizationalRole | 11,12,13 | commonName |
- | | 15 | organizationalPerson | 11,12,13 | commonName |
- +----------------+-----+----------------------+----------+-------------+
- | application | 16 | applicationProcess | 11,12,13 | commonName |
- | | 17 | nadfApplicationEntity| 16 | commonName |
- | | 18 | groupOfNames | 11,12,13 | commonName |
- | | 19 | ediUser | 11,12,13 | ediName |
- | | 20 | device | 11,12,13 | commonName |
- +----------------+-----+----------------------+----------+-------------+
-
- Or, in pictorial form:
-
- (------------)
- (organization)
- (------------)
- |
- |<------------------------------+
- | |
- +--->(organizationalUnit)-------+
- | |
- +--->(locality)-----------------+
- |
- +--->(organizationalRole)
- |
- +--->(organizationalPerson)
- |
- +--->(applicationProcess)--->(nadfApplicationEntity)
- |
- +--->(groupOfNames)
- |
- +--->(ediUser)
- |
- +--->(device)
-
-
- 6.2. Persons
-
- Listing organizational persons is a local matter to be decided by
- each organization.
-
- Residential persons are identified by the place where they reside,
-
-
-
- NADF [Page 16]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- usually with a multi-valued RDN consisting of a "commonName"
- attribute value, and some other distinguished attribute value.
- Although an obvious choice is to use something like "postalCode" or
- "streetAddress", it should be noted that this information may be
- considered private. Hence, some other, distinguishing attribute
- value may be used -- possibly even a "serial number" attribute value
- which has no other purpose other than to give uniqueness. (It should
- be noted that an attribute of this kind is not helpful in regards to
- searching -- other attribute values containing meaningful information
- should be added to the entry and made available for public access, as
- an aid to selection.)
-
- The RDN used when listing residential persons depends on where the
- listing is to be placed:
-
- +----------------------------------------+
- +-------------------| Listing (RDN) under |
- | Entity | c=US | c=US, st=X | c=US, st=X, l=Y |
- +-------------------+---------+------------+-----------------+
- | residential | cn, ... | cn, ... | cn, ..., fips55 |
- | person | st=X | fips55 | |
- | | fips55 | | |
- +-------------------+---------+------------+-----------------+
- | .. (other region) | | cn, ... | cn, ..., st=Z |
- | | | st=Z | fips55 |
- | | | fips55 | |
- +-------------------+---------+------------+-----------------+
-
- Note that listing of foreign persons is for further study.
-
- 7. Usage Examples
-
- In the examples which follow, the "*"-character is used to denote any
- arbitrary value for an attribute type.
-
- 7.1. Organizations with National-Standing
-
- Suppose that the organization
-
- Lawrence Livermore National Laboratory
-
- has national-standing by virtue of having been chartered by the US
- Congress. According to the table in Section 6.1, this organization
- has the right to list as any (or all) of these names:
-
- (1) national-listing:
-
- { c=US,
-
-
-
- NADF [Page 17]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- o=Lawrence Livermore National Laboratory }
-
-
- (2) regional-listing:
-
- { c=US, st=*,
- { o=Lawrence Livermore National Laboratory,
- c=US } }
-
-
- (3) local-listing:
-
- { c=US, st=*, l=*,
- { o=Lawrence Livermore National Laboratory,
- c=US } }
-
- Suppose that the organization
-
- Performance Systems International, Inc.
-
- has national-standing by virtue of having an alphanumeric nameform in
- the ANSI registry. According to the table in Section 6.1, this
- organization has the right to list as any (or all) of these names:
-
- (1) national-listing:
-
- { c=US, o=Performance Systems International }
-
-
- (2) regional-listing:
- { c=US, st=*,
- { o=Performance Systems International, c=US } }
-
-
- (3) local-listing:
-
- { c=US, st=*, l=*,
- { o=Performance Systems International, c=US } }
-
- 7.2. Organizations with Regional-Standing
-
- Suppose that the organization
-
- Network Management Associates, Inc.
-
- has regional-standing by virtue of having a DBA registration with the
- Secretary of State for the State of California. According to the
- table in Section 6.1, this organization has the right to list as any
-
-
-
- NADF [Page 18]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- (or all) of these names:
-
- (1) national-listing:
-
- { c=US,
- { o=Network Management Associates,
- st=California } }
-
-
- (2) regional-listing:
-
- { c=US, st=California,
- o=Network Management Associates }
-
-
- (3) local-listing:
-
- { c=US, st=California, l=*,
- o=Network Management Associates }
-
- Further, in some state other than California, this
- organization might also list as:
-
- (1) regional-listing:
-
- { c=US, st=*,
- { o=Network Management Associates,
- st=California } }
-
-
- (2) local-listing:
-
- { c=US, st=*, l=*,
- { o=Network Management Associates,
- st=California } }
-
- 7.3. Organizations with Local-Standing
-
- Suppose that the tavern and eatery
-
- St. James Infirmary
-
- has local-standing by virtue of having a DBA registration with the
- City Clerk for the City of Mountain View in the State of California.
- According to the table in Section 6.1, this organization has the
- right to list as any (or all) of these names:
-
- (1) national-listing:
-
-
-
- NADF [Page 19]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- { c=US,
- { o=St. James Infirmary, st=California,
- fips55=49670 } }
-
-
- (2) regional-listing:
-
- { c=US, st=California,
- { o=St. James Infirmary, fips55=49670 } }
-
-
- (3) local-listing:
-
- { c=US, st=California, l=*,
- { o=St. James Infirmary, fips55=49670 } }
-
- Further, in some state other than California, this
- organization might also list as:
-
- (1) regional-listing:
-
- { c=US, st=*,
- { o=St. James Infirmary, st=California,
- fips55=49670 } }
-
-
- (2) local-listing:
-
- { c=US, st=*, l=*,
- { o=St. James Infirmary, st=California,
- fips55=49670 } }
-
- 7.4. Organizations with Foreign-Standing
-
- Suppose that the five-star restaurant
-
- Erik's Fisk
-
- has foreign-standing by virtue of having a DBA registration
- throughout Sweden. According to the table in Section 6.1, this
- organization has the right to list as any (or all) of these names:
-
- (1) national-listing:
-
- { c=US,
- { o=Erik's Fisk, c=SE } }
-
-
-
-
-
- NADF [Page 20]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- (2) regional-listing:
-
- { c=US, st=*,
- { o=Erik's Fisk, c=SE } }
-
-
- (3) local-listing:
-
- { c=US, st=*, l=*,
- { o=Erik's Fisk, c=SE } }
-
- 7.5. Persons
-
- Suppose that the person
-
- Marshall T. Rose
-
- residing in the City of Mountain View in the State of California,
- wishes to be listed in the Directory. According to the table in
- Section 6.2, this person might be listed as any of these names:
-
- (1) national-listing:
-
- { c=US,
- { cn=Marshall T. Rose, postalCode=94043-2112,
- st=California, fips55=49670 } }
-
-
- (2) regional-listing:
-
- { c=US, st=California,
- { cn=Marshall T. Rose, postalCode=94043-2112,
- fips55=49670 } }
-
-
- (3) local-listing:
-
- { c=US, st=California, l=Santa Clara,
- { cn=Marshall T. Rose, postalCode=94043-2112 } }
-
- Further, in some state other than California, this person
- might also list as:
-
- (1) regional-listing:
-
- { c=US, st=*,
- { cn=Marshall T. Rose, postalCode=94043-2112,
- st=California, fips55=49670 } }
-
-
-
- NADF [Page 21]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- (2) local-listing:
-
- { c=US, st=*, l=*,
- { cn=Marshall T. Rose, postalCode=94043-2112,
- st=California, fips55=49670 } }
-
- 8. Bibliography
-
- X.500:
- The Directory -- Overview of Concepts, Models, and Service,
- CCITT Recommendation X.500, December, 1988.
-
- US FIPS 5:
- Codes for the Identification of the States, The District of
- Columbia and Outlying Areas of the United States, and
- Associated Areas, US Department of Commerce FIPS 5-2, May
- 28, 1987.
-
- US FIPS 55:
- Guideline: Codes for Named Populated Places, Primary County
- Divisions, and other Locational Entities of the United
- States and Outlying Areas, US Department of Commerce FIPS
- 55-2, February 3, 1987.
-
- Appendix A: Revision History of this Scheme
-
- The first version of this scheme (NADF-71) was contributed to the
- North American Directory Forum at its November 27-30, 1990 meeting.
- The (mis)features were:
-
- (1) Because of the lack of confidence in ANSI registration
- procedures, it was proposed that the US trademarks be
- used as the basis for RDNs of organizations with
- national-standing.
- This proved unworkable since the same trademark may be
- issued to different organizations in different
- industries.
-
- (2) There was no pre-existing registry used for populated
- places.
- This proved unworkable since the effort to define a new
- registry is problematic.
-
- The second version of this scheme was contributed to the ANSI
- Registration Authority Committee at its January 30, 1991 meeting, and
- the IETF OSI Directory Services Working Group at its February 12-13,
- 1991 meeting. The (mis)features were:
-
-
-
-
- NADF [Page 22]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- (1) The ANSI numeric name form registry was used as the
- basis for RDNs of organizations with national
- standings.
-
- (2) The FIPS 5 state numeric code was used as the basis for
- RDNs of states and state-equivalents.
-
- (3) The FIPS 55 place numeric code was used as the basis
- for RDNs of populated places.
-
- The choice of numeric rather than alphanumeric name forms was
- unpopular, but was motivated by the desire to avoid using the ANSI
- alphanumeric name form registry, which was perceived as unstable.
-
- The third version of this scheme was contributed to US State
- Department Study Group D's MHS-MD subcommittee at its March 7-8 1991
- meeting. That version used alphanumeric name forms for all objects,
- under the perception that the ANSI alphanumeric name form registry
- will prove stable. If the ANSI alphanumeric name form registry
- proves unstable, then two alternatives are possible:
-
- (1) disallow organizations with national-standing in the US
- portion of the DIT; or,
-
- (2) use the ANSI numeric name form registry instead.
-
- Hopefully neither of these two undesirable alternatives will prove
- necessary.
-
- The fourth version of this scheme (NADF-103) was contributed to the
- NADF at its March 18-22, 1991 meeting. This version introduced the
- notion of organizations with regional standing being listed at the
- national level through the use of alias names and multi-valued RDNs.
-
- The fifth version of this scheme (NADF-123) was produced at the NADF
- meeting (and also published in the Internet community as RFC1212).
- This version generalized the listing concept by introducing the
- notion of optimized civil naming. Further, the document was edited
- to clearly note the different naming sub-structures and the relation
- between them.
-
- The sixth version of this scheme (NADF-143) was contributed to the
- NADF before its July 9-12, 1991 meeting, and was edited to reflect
- comments received from the Internet and other communities. The
- changes were:
-
- (1) The schema definitions were removed from Appendix A and
- placed in a separate document, NADF-132. In NADF-132:
-
-
-
- NADF [Page 23]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- the prefix object-identifier was changed (the original
- assignment was in error); and, the definition of a
- "nadfADDMD" object was considerably expanded.
-
- (2) States and state-equivalents are now named using
- attribute values of "stateOrProvinceName".
-
- (3) Populated places now correspond to counties, though
- FIPS 55 is still used extensively.
-
- (4) The text of this document was reworked to more clearly
- distinguish between registration and listing.
-
- (5) The "foreignOrganization" and "fips55Object" object
- classes were added.
-
- The seventh version of this scheme (NADF-166) was produced at
- the NADF meeting. It made a few changes:
-
- (1) It was noted that organizations with local standing may
- need additional distinguishing attributes when listing.
-
- (2) The "usOrganization" object class was removed and
- replaced with the auxiliary object class
- "ansiOrgObject".
-
- (3) The "foreignOrganization" object class was removed and
- replaced with the auxiliary object class
- "nationalObject". This may be used when listing any
- organization of national standing (regardless of
- whether that organization is US-based). For example,
- an organization with US national-standing would need
- this when being listed at the regional or local level.
-
- (4) Figures corresponding to the DIT structures were added,
- along with some minor additional text in the usage
- examples.
-
- (5) The Acknowledgements section, long out of date, was
- removed.
-
- The eighth (current) version of this scheme was produced after
- the NADF meeting. It corrects a few typographical errors.
-
-
-
-
-
-
-
-
- NADF [Page 24]
-
- RFC 1255 A Naming Scheme for c=US September 1991
-
-
- Security Considerations
-
- Security issues are not discussed in this memo.
-
- Author's Address
-
- North American Directory Forum
- c/o Theodore H. Myer
- Rapport Communication, Inc.
- 3055 Q Street NW
- Washington, DC 20007
-
- Tel: +1 202-342-2727
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- NADF [Page 25]
-